Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-069.TXT

Text File | 1992-06-03 | 35.7 KB | 900 lines

C.S.M.P. Digest             Sat, 02 May 92       Volume 1 : Issue 69

Today's Topics:

    Confusion on WDID, DirID, Vref
    MacHack '92 Announcement
    Patching a trap for print jobs...


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Phil Hunt)
Subject: Confusion on WDID, DirID, Vref
Date: 31 Mar 92 20:37:51 GMT
Organization: Howtek, Inc.

Hi,

I am having some trouble with the ID values for DirId, WDID, and vref


I know, Stdfil dialog returns a vref that is really the WD (or Dir)ID of the
directory  the file specified is located on.....Then, throughout my program,
I use that returned value and the actual filename to get to my pref file

Well, now I want to be able to do my rpgoram in 'batch', meaning, running
from a command file, so I changed my program to allow the user (or command
file) to enter a 'FULLY QUALIFIED PATH/FILENAME'...The Open calls use this
correctly, but I need to be able to get the same type of Dir (or WD) id that
stdfil gave me...In other words, I want to find the File with a full pathname,
get the ID of where the file is and just keep the ID and the filename

I used FSOPEN, it returned a 'access path ID'...I then ran that through GetvRef,
but it returned (-3), which is my VOLUME reference, not the directory reference

How do I do this?  It must be something I am overlooking!

Phil

- ------------------------------------------------------------------------
Phil Hunt                                                  [phone]
Howtek, Inc.                           "Wherever you go, there you are!"

Internet: [e-mail]         uucp: {decvax|harvard}!mv!phunt!phil

+++++++++++++++++++++++++++

From: [e-mail] (Jeffrey T. Hutzelman)
Date: 1 Apr 92 00:38:34 GMT
Organization: Sophomore, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA



On 31-Mar-92 in Confusion on WDID, DirID,
user Phil [e-mail] writes:
>Hi,
>
>I am having some trouble with the ID values for DirId, WDID, and vref
>
>
>I know, Stdfil dialog returns a vref that is really the WD (or Dir)ID of the
>directory  the file specified is located on.....Then, throughout my program,
>I use that returned value and the actual filename to get to my pref file
>
>Well, now I want to be able to do my rpgoram in 'batch', meaning, running
>from a command file, so I changed my program to allow the user (or command
>file) to enter a 'FULLY QUALIFIED PATH/FILENAME'...The Open calls use this
>correctly, but I need to be able to get the same type of Dir (or WD) id that
>stdfil gave me...In other words, I want to find the File with a full pathname,
>get the ID of where the file is and just keep the ID and the filename
>
>I used FSOPEN, it returned a 'access path ID'...I then ran that through
GetvRef,
>but it returned (-3), which is my VOLUME reference, not the directory
reference
>
>How do I do this?  It must be something I am overlooking!
>
>Phil

Well, there are several things you can do, that I can think of:

What you seem to be asking for is a way to get a working directory
reference number for the directory the file is in.  However, WD numbers
are assigned dynamically as programs ask for them.  You can get one by
calling PBOpenWD or its high-level equivalent, but it won't be the same
the next time your program runs.

What you WANT is to get the vRefNum of the volume the file is on, AND
the dirID of the directory the file is contained in.  These will
uniquely identify the file forever, as long as that volume gets the same
vRefNum the next time the machine starts up, which it normally will,
unless removable volumes or fileservers are involved, in which case all
bets are off.  You can get the vRefNum, dirID, and filename by calling
PBGetCatInfo on the full pathname.

The best way to keep track of such a file would be to store either the
full pathname (calling PBGetCatInfo when you read the name to get
vRefNum and dirID, if you really need them), or store the volume name,
dirID, and filename.  Of course, this still fails if there are 2 volumes
with the same name.

Finally, if you are willing to be System 7 dependant, you can use the
alias manager to create an alias record for the file, and then use it to
resolve the alias when you want to get at the file.  I believe resolving
an alias record results in an FSSpec, which can be trivially converted
into a vRefNum, dirID, and filename.

- -- Jeffrey Hutzelman

[e-mail], [e-mail]
JeffreyH11 on America Online

---------------------------

From: [e-mail] (Waldemar Horwat)
Subject: MacHack '92 Announcement
Date: 31 Mar 92 23:50:19 GMT


MacHack '92 - The Seventh Annual Macintosh Technical Conference
June 17 - 19, 1992
Ann Arbor, Michigan

For the seventh year, MacHack(tm) provides a forum specifically for software
developers for the Macintosh(r) family of computers. The conference provides
developers a full spectrum of information about hardware, developers' software,
and support at a high level of complexity and application.

The conference includes:
  Panels
  Papers
  Roundtables
  Code Clinics
  24-Hour Machine Room
  Business Sessions
  Vendor Showcases
  Lots of opportunities to meet Apple engineers and other Mac software
    developers


Panels

These panel sessions constitute the core of the conference. Ranging over a wide
variety of topics, the panels address areas of current interest to Macintosh
programmers.  Some of the topics are listed below:

MacHack 101
This session is a light hearted introduction to MacHack, its customs, and
expectations. It will introduce the first time MacHacker to how things work and
where to find them, and give the seasoned veteran a look at the new features
and scheduling.

Essence of the Hack
The raison d'etre of MacHack is the hack. Discover the essential elements of
creating a hack: hooking in, laying low, following the rules.

Graphics
This session will focus on new graphics support coming from Apple. If you are
at all interested in graphics, or even if you are not, this is probably a
session you will want to attend!

Networking
No computer is an island. From the basic one Macintosh and a printer to the
largest corporations and universities, networks are the basis of communications
between computers. With publish and subscribe an integral part of the
operating system, it is becoming more and more essential to have your work
network compatible. Learn networking secrets here.

RISC
Find out the low-down about Apple's new RISC development and what it means to
developers. Are you going to have to rewrite all your apps from scratch?

Coming Attractions in System Software
Get the inside scoop on new things planned for system software, from the people
actually doing them.

Stump the Panel
Bring your toughest questions for this panel of Gurus, and other know-it-alls!
No holds barred. Try to stump them! (The panel is armed with all its
knowledge!) Special prizes for stumping the panel.

QuickTime(tm)
An in-depth look at the QuickTime software architecture, its uses and
ramifications. Find out how you can use QuickTime in your applications, and
what you need to do to make it work.

Future of MPW
Is MPW an Edsel, doomed to extinction, a Volkswagen with a future in
collectibles, or Corvette ZR1 on the cutting edge and getting better? Where is
MPW going? What sort of things can you expect from Apple's development system
in the future?

Poor Man's OOP
A personal encounter with object oriented programming. One man's experience
with Smalltalk and an introduction for you.

Graphics Acceleration
It used to be simple. Black & white, 72dpi, 9 inch screen and one interface.
Not so anymore. With color the new standard and several new ways of getting
images on-screen, even the new built-in graphics devices can't keep up. Get the
scoop on graphics acceleration here.

Hyperzealot!
Hear about hypercard, its past, present and future.... and see some nifty keen
demos of quicktime and color in hypercard from one of the senior engineers on
the hypercard project.

Translation XTND and Beyond
Why has Apple been encouraging you to write XTND translators for your document
formats? Is there life beyone XTND? Come talk to someone who knows.

Innards of the File System
The current King of HFS will walk thru the internals of the file system,
explaining every last secret of the file system. Well, maybe not all of them...

Collaborative Computing
Find out what Apple's Collaborative computing is all about. Why all the hoopla
anyway?

Apple Feedback
Here is your chance to send information back to Apple, about what they are
doing wrong, and more importantly, what they are doing right! Bring your
questions and comments to Apple's cast of tens. Find out from the perpetrators
why certain decisions were made and let your feelings about Apple's policies be
known where it counts.


Papers

Ten academic papers will be presented on programming at the cutting edge. The
text of the papers will be distributed to all conference attendees.

The Construction of a TCP/IP to AppleEvent Gateway for Use in Distributed
Computing Experimentation
   Christopher Haupt    RIT/SCI

Object-PatchWorks
   Patrick Beard        Berkeley Systems

Optimizing Source Code
   Shane Looker

Experiences from the Development of Harvest C
   Eric Sink            USACERL

Putting an Object-Oriented Face on a Toolbox Manager: How to use OOP to manage
toolbox complexity
   Ralph Krug

Passing the Torch: Enabling the next generation of hackers
   Tom Pittman

Macintosh Common Lisp
   Mike Engber

Cognits: A portable library of intelligent classes
   Dr. Steven Lewis     The Aerospace Corp

Euclid: Collaborative reasoning with hypertext
   Bernie Bernstein

Macintosh and Microsoft Windows 3.0: A developer's perspective
   Waldemar Horwat


Roundtables

Roundtable sessions will consist of a moderator, attendees, a Macintosh, and a
dedicated area. Session topics are as specific or as general as desired. Topics
are scheduled either dynamically or in advance; if there is a specific topic
you wish to see discussed, call Expotech to arrange for a roundtable time.
Moderators of roundtables that are scheduled before May 1st may be eligible
for the speaker discount.


Code Clinics

In addition to the regularly scheduled sessions, there will be "Code Clinics"
where some of the most talented code-hackers attending actually dissect, debug,
and comment on code. Real, hands-on sessions up close and personal with that
code. Sessions include:
   Color Quickdraw
   File System - HFS
   AppleTalk Protocols
   Memory Management
   AppleEvents
   International Problems
   System Extensions - INITs, drvrs etc.   System 7 coolness
   Managing resources
   Sound


Machine Room

One of the most heavily used areas of MacHack every year is the "Machine Room",
open 24 hours per day.  Using equipment donated by the University of Michigan,
Apple Computer, and many other organizations, attendees are encouraged to
program, collaborate, try out ideas, and design throughout the conference.



Business Sessions

A series of presentations on setting up, managing, financing, and protecting a
software company. Note: class size is limited, and there is a small surcharge
for attending business sessions.

Introduction to Suits and Weasels
a review of basic business requirements, including a guide to telling the role
of the person you are talking to by haircut and tie.

Business Plan Basics
This is an overview of all the parts of a business plan and what needs to go
into them. Not only for a Vulture capitalist or a bank, but so you can keep
friends, friends and avoid lawsuits.

Marketing Plans
An overview of the Macintosh market, how to determine market size and how to
write a marketing plan that has meaning, outside the bathroom.

Mating Rituals 1 - Attracting a publisher
This is the first session in how to get married and make money for both
partners. You will learn the waltz in this session. Also tips on flirting with
a publisher.

Mating Rituals 2 - What a publisher is looking for in an author
What does the publisher want in an author and a product. Why redheads have more
success at a party. What not to wear to the party.

The Family Feud
Now that they are married these publisher/author combinations discuss the
intimate facts of their marriages and why they are still together.

Getting 5 Mice (5 stars) - Working with the press
Here is a panel on how to get the press to like you and your product, care and
feeding of your favorite editor and how to pick one.

Project terms
A quick review of the lingo of Pert and Gantt. Or how to speak the language of
projects without offending your host.

Software Project Planning
We have MacApp and C++ but the basic rules still apply for determining how long
and how hard you have to work to finish a project. This is a review of the
basic rules to planning projects, so the cupboard does not run bare.

Project Management
You can not finish all the software yourself, so sometimes, you need to get
other people to help, how to manage that process and make the right calls for a
project that is on track and one that left the track weeks ago.

The Basics of Software Contracts - Or - Why lawyers are like ICBMs
`Nuff Said!

What You Need to Know About
Patents, Copyrights, and Trademarks

Protecting the Crown Jewels -
An introduction to trade secrets
Shhhhh! We could tell you but then we would have to shoot you.

Bundling & Co-marketing
How to leverage the market and get the combination packages together and sell
them to the public without incuring major expense.

Getting Bucks -
Surviving the venture capitalists
and if you don't succeed how to live with Danny DeVito as your new boss.

Contract Programming
How to make money with your fingers.

Work For Hire
This is a review of what the term means and why you do not own your own code
anymore.

Tech Writing Workshop
If you like the manual, you will love the movie. A panel on how to make your
manuals more witty and readable than this brochure from pros who do it all the
time.

On-line Help Systems
A look at why the manual may not be enough and what belongs in your help system
for both system 6 and 7.

Business Plan Review
A working Brunch for the first 6 people to sign up. It will run with
interuptions all day Saturday until the party starts. Review the Business Plan
that you wrote during your spare time since Wednesday morning.


Vendor Showcase

Representatives of companies who are also conference attendees will be making
scheduled presentations of products that are of interest to programmers.


Important Details

MacHack '92 will consist of no more than 300 of the best programmers in the
Macintosh world. In addition, we make every effort to keep prices reasonable.
The costs to attend are:
   Prior to 4/16/92 - $295.00
   4/16/92 or after - $345.00
   Full-time student-  $50.00 (no lunches or banquet)
The fee includes admittance to the conference sessions, copies of the
proceedings on disk and on paper, three lunches, one banquet, and breaks.
It can, as usual, cost you even less. As an invited speaker at one or more of
the sessions, the cost is only:
   Speaker - prior to 4/16/92 - $195.00
   Speaker - 4/16/92 or after - $245.00

Location

The conference will take place at the Ann Arbor Holiday Inn - West, 2900
Jackson Road, Ann Arbor, MI 48103. Call 313-665-4444 for reservations.  Make
sure the hotel knows you are with MacHack '92 to receive the special rate of
$64/single-night or $74/double-night.

Speaking

It may still be possible to sign up to speak on some of the topics or moderate
a roundtable (and thus qualify for a reduced fee). If you feel qualified and
willing to speak on one of these topics, contact Aimee Moran at Expotech.

Registration

To request more information or to register, call Expotech at 313-882-1824.

+++++++++++++++++++++++++++

From: [e-mail] (Christopher Huckabay Modeller Tate)
Date: 1 Apr 92 02:54:19 GMT
Organization: Penn State University

Would it be possible for someone (or perhaps sometwo or -three) to
summarize a few of the juicy details that come out of MacHack to
the net?

For example, I'd love to hear what they have to say on RISC, on the
new graphics support, and on graphics acceleration, but I've got the
proverbial snowball's chance in Pittsburgh of actually making it to
the conference....

- -------
Christopher Tate     | Cryptogram #11:
[e-mail] |
[e-mail]  | "KOI SDXG EDKZZ QXKS SDXMN EAHNIE MOSH CZHAEDKNXE,
- ---------------------|  YHN MY GHV DMS K BKO AMSD K CZHAEDKNX, DX'E UHMOU
Send me the answer!  |  SH TOHA DX'E QXXO DMS."   (QNVFX DHVZS)

---------------------------

From: [e-mail] (Bertrand Limoges)
Subject: Patching a trap for print jobs...
Date: 28 Feb 92 21:58:54 GMT
Organization: Sobeco Ernst & Young Inc.

Hi,

I need a dialog to come up every time someone prints from an application.
This has to work with any application so I can only think of an INIT to
do the work. However I don't really want to patch _PrGlue (0xA8FD) if I
can avoid it, since it gets called several times during the printing
process (and even to set up default printing record when apps start up)
and I would have to check the stack for the value that says PrOpenDoc,
for example.

So, does anyone have any alternate suggestions? If not, could I get a
few tips on restoring the stack before jmp'ing to the original trap
address once my code is done. I'm using THINK C, and when I patch for
PrOpenDoc I have to check if the parameter is 0x0400 0x0C00 and if not
I attempt to move the value back on the stack and jmp to the original
address, but I can't seem to succeed. If there is no alternative, I'll
post some code I tried for more specific info.

Thanks, Bertrand



- -------------------------

From: [e-mail] (Pete Gontier)
Date: Mon, 02 Mar 1992 21:05:43 -0500

 BL> From: [e-mail] (Bertrand Limoges)

 BL> I need a dialog to come up every time someone prints from an application.
 BL> This has to work with any application so I can only think of an INIT to
 BL> do the work. However I don't really want to patch _PrGlue (0xA8FD) if I
 BL> can avoid it, since it gets called several times during the printing
 BL> process (and even to set up default printing record when apps start up)
 BL> and I would have to check the stack for the value that says PrOpenDoc,
 BL> for example.

 BL> So, does anyone have any alternate suggestions? If not, could I get a
 BL> few tips on restoring the stack before jmp'ing to the original trap
 BL> address once my code is done...

Go ahead and patch the bastard. It's not so awful.

I haven't looked at this code in a while -- I remember it worked as of some
time late last year, under both System 7 and System 6.

Have fun. Four spaces to the tab, BTW.

/**************************************************************************/

static Boolean PasswordDialog(void) {
    Rect boundsRect;
    unsigned char *ditlS = "\p000300000000003600D0004A010A04024F4B0000000000360086004A00C0040643616E63656C000000000012000B00220056880950617373776F72643A0000000000001200590022010A9000";
    short itemHit; DialogPtr passD;
    Handle ditl = NewHandle((*ditlS / 2) + 1);

    if (!ditl) return(false);
    StuffHex(*ditl,ditlS); SetRect(&boundsRect,40,40,350,150);
    passD = NewDialog(nil,&boundsRect,"\p",true,dBoxProc,(WindowPtr) -1,false,0,ditl);
    if (!passD) { DisposeHandle(ditl); return(false); }
    InitCursor( );
    do {
        ModalDialog(nil,&itemHit);
    } while (itemHit != OK && itemHit != Cancel);
    DisposeDialog(passD);
}

static void * PrJobDialogPatch(void *pOldAddress) {
    asm {
            LEA            @jmpOld,A0
            ADDQ.L        #2,A0
            MOVE.L        pOldAddress,(A0)
            LEA            @patch,A0
            MOVE.L        A0,D0
            BRA.S        @out
@patch:        CMPI.L        #0x32040488,4(A7)        ; check for PrJobDialog
            BEQ.S        @go
            CMPI.L        #0x4A040894,4(A7)        ; check for PrDlgMain
            BNE.S        @jmpOld
@go            JSR            PasswordDialog
@jmpOld:    JMP            'PrGl'
@out:
    }
}

/***********************************************************************/

#define kTrapNumberMask            0x07FF
#define kUnimplementedTrapWord    0xA89F

static void * AS_GetTrapAddress (short trapWord) {
    return ((void *) NGetTrapAddress (trapWord & kTrapNumberMask, (trapWord & 0x0800) ? ToolTrap : OSTrap));
}

static void AS_SetTrapAddress (void *proc, short trapWord) {
    NSetTrapAddress ((long) StripAddress(proc), trapWord & kTrapNumberMask, (trapWord & 0x0800) ? ToolTrap : OSTrap);
}

#define _PrGlue 0xA8FD

void main(void) {
    void *me; asm { MOVE.L A0,me }
    DetachResource(RecoverHandle(me));
    AS_SetTrapAddress(PrJobDialogPatch(AS_GetTrapAddress(_PrGlue)),_PrGlue);
}

+++++++++++++++++++++++++++

From: [e-mail] (Tom Dowdy)
Date: 8 Mar 92 18:03:17 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Bertrand Limoges) writes:
> I need a dialog to come up every time someone prints from an application.
> This has to work with any application so I can only think of an INIT to
> do the work. However I don't really want to patch _PrGlue (0xA8FD) if I
> can avoid it, since it gets called several times during the printing
> process (and even to set up default printing record when apps start up)
> and I would have to check the stack for the value that says PrOpenDoc,
> for example.

I hate to rain on your parade here - but patching PrGlue alone won't
do it.  The reason is kind of complexicated, but if you are willing
for a story, here goes:  (I'm sure someone like Dave will jump in
and correct any historical inaccuracies.  I'm just a "new" oldtimer here,
coming up on my first 5 years)

Back in the good old days, there was no printing trap.  In fact,
there were no printer drivers either (at least, not in the sense
that we know them today).  Instead there was a low level 'DRVR' that
was called with the correct set of parameters to make requests.
Rather than having to remember all of those icky paramBlocks, some
folks thought of writing some glue code as well to make it easier
for programmers.

Later in the Mac development game, the idea that these low level
drivers probably weren't enough came up.  Thus was born the
high level printing manager interface that we all know and hate
today.  However (I suspect) it was too late in the Mac development
cycle to add another trap (and/or the ROMs were full), so PrGlue
was really just a set of libraries that basically ended up doing an
OpenResFile, GetResource, HLock, JMP on the various PDEFs. This all
probably made sense at the time, because they already had this handy
library called PrGlue to stuff things into.

Aside: rumor has it that the _PrGlue trap had actually been allocated
for the Print Manager as early as 1982 or 83, but for some other
reason wasn't included in the ROM.  I once again claim a combination
of space and/or timing.

And then the Mac was released, and apps started to be written.
Every app linked with PrGlue, but some of them actually wrote their
own and linked with THAT - after all, it's just library code.
Microsoft was particularlly a big fan of redoing
the glue to conform to their own idea of how things should be done.
If you ever want to hear a big rant, just ask a PrintShop person about
"the Seattle font".

When the Plus was released, the allocated PrGlue trap was finally
used, and the PrGlue library was changed to use the trap when it
was implemented (or to continue to call the old way if it was not).
In theory, this would solve the problem because now there was a trap
available - thus allowing patching once all of the applications were
converted over.

Unfortunatly for our hero (or anyone wanting to change how the printing
manager works) there were already zillions (or thousands) of applications
out there that were linked with a PrGlue library that did NOT use the
trap.  I venture to guess that a decent percentage of new versions of
applications today still are using the old-style glue in some way (sometimes
they'll use old style glue for some calls, and the trap for others - Whee!)

When 7.0 came out, we had to do some pretty evil patching to move the
printer drivers into the exentions folder, because of all of these
apps (and glue) out there that were assuming they could just OpenResFile
to get at the driver.  (And when I say "we" here, I mean somebody
other than me).  I don't really want to go into the specifics here because:
 a) I don't know what they all are, and am loath to give a half answer

 b) it's very complex, and not something Joe Average INIT writer should
    try to tackle (especially if he's scared to even patch PrGlue).

 c) it's not gonna work in the future.

This all doesn't even get into the fact that there are actually multiple
versions of the glue out there, and also that lots of apps call the
printing manager incorrectly, so you have to watch for things like
PrValidate before a call to PrOpen, or a call to PrClose without a call
to PrOpen.  Or two calls to PrClose (*really* close the Printing Manager).
Oh, and don't forget the ever popular "forgetting to call PrClose
at all" - it's a BIG hit.

Here endeth the lesson - oh yeah, I *am* in the PrintShop - where a sense
of humor is your only defense from sticking yourself with a knife.

 Tom Dowdy                 Internet:  [e-mail]
 Apple Computer MS:81KS    UUCP:      {sun,voder,amdahl,decwrl}!apple!dowdy
 20525 Mariani Ave         AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

From: [e-mail] (David Casseres)
Date: 9 Mar 92 18:33:41 GMT
Organization: Apple Computer Inc.

In article <[e-mail]>, [e-mail] (Tom Dowdy) writes:

[A lengthy and helpful explanation of why it won't do to just patch the printing
trap, including the following]

> I hate to rain on your parade here - but patching PrGlue alone won't
> do it.  The reason is kind of complexicated, but if you are willing
> for a story, here goes:  (I'm sure someone like Dave will jump in
> and correct any historical inaccuracies.  I'm just a "new" oldtimer here,
> coming up on my first 5 years)
>
> Back in the good old days, there was no printing trap.  In fact,
> there were no printer drivers either (at least, not in the sense
> that we know them today).  Instead there was a low level 'DRVR' that
> was called with the correct set of parameters to make requests.
> Rather than having to remember all of those icky paramBlocks, some
> folks thought of writing some glue code as well to make it easier
> for programmers.
>
> Later in the Mac development game, the idea that these low level
> drivers probably weren't enough came up.  Thus was born the
> high level printing manager interface that we all know and hate
> today....

This is the only historical inaccuracy, so here comes the Historical Accuracy
Police:

I'm pretty sure the high-level interface came first in the original design
process, as it bore a fairly close resemblance to the one used in the Lisa.  At
first release of the Mac, though, the whole amazing "architecture" of printing
was in place, except for the trap and the Wonderful Chooser.  The only printer
type was of course the ImageWriter, and we had both a low-level DRVR type driver
implementing the low-level, ASCII-based interface and the high-level,
raster-based interface.  The DRVR was called directly, and the high-level PDEF
was called via the PrGlue library, which was shipped to developers as a linkable
object.  The original reason for PrGlue was to do all the business of finding
and loading up a PDEF code resource and jumping into the right entry point.

When the LaserWriter came along, the Wonderful Chooser was invented by a middle
manager as the solution to having more than one kind of printer to talk to.  It
meant that the application and the print code itself did not know what kind of
printer to print on without going on a treasure hunt to find the information
left by the Chooser.  So PrGlue had to be rev'ed so it would do that.  That's
when we began to realize how bad it was to depend on a linkable library --
applications couldn't do the right thing unless their developers relinked them
and shipped out the revision.  Guess how popular that was!  That's why we
finally got the trap implemented, so that applications could make generic calls
to the trap and the system software behind the trap would do the right thing for
the current printer.  Or implement any other revs we might dream up, without
requiring app developers to do anything.

The original idea behind the separation of low-level and high-level printing
interfaces was that on a 128K Mac there might not be enough space to load up the
PDEF of the high-level interface.  In that desperate case the app could still
print using the low-level DRVR interface, since it was very small.  I don't know
of any major app that actually took advantage of this, though.

So the ImageWriter had completely separate implementations of the high- and
low-level functionalities, though there was at one time a design in which the
high-level PDEF did everything by calling the low-level DRVR.

The LaserWriter did use that design.  The high-level PDEF talked only to the
low-level DRVR, which talked to the printer.  By the time I did the code for the
LaserWriter IISC, though, it was clear that we didn't actually need a separate
DRVR for anything real.  So I had to keep the DRVR, since apps still called it,
but I made it do everything by calling the PDEF -- thus reversing the original
design.  This simplified the implementation a *lot,* as the DRVR became a mere
shell.

And a last footnote, just to show how gnarly and weird some of the old original
Mac design was:  there was a strange, sick relationship between QuickDraw, the
Font Manager, and the low-level print DRVR.  When drawing styled text, either QD
or the FM, I forget which, would need to know some numbers to characterize
things like how much to slant the image for "italic" text, how much to offset
the double-strike for "bold," how much to adjust the character spacing for each
of these, and so forth.  Guess how it got those numbers?  Why it *called the
current print DRVR,* of course.  And the DRVR had those numbers hard-coded in
it, so the printer code designer could affect the way styled text was actually
imaged for that particular printer, except for the final great joke in this
design, which was that most of those numbers actually had no effect whatsoever,
because the code that was supposed to use them never worked.

I put all of this in the past tense, because I left the PrintShop several years
ago and have no idea how much progress Tom and the other brave souls over there
have made on this stuff.  And you know what, I'm happier that way...

- --

David Casseres
Exclaimer: Wow!

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Wed, 11 Mar 1992 16:38:15 GMT

In article <[e-mail]> [e-mail] (Tom Dowdy) writes:
>When the Plus was released, the allocated PrGlue trap was finally
>used, and the PrGlue library was changed to use the trap

Nitty-picky-osity:  _PrGlue appeared with System 4.0 (I believe) which came
out a good while after the Mac Plus.  In fact, it was the system version
released with the very earliest Mac SEs.  I could be slightly off on my
release numbers, but I'm certain that _PrGlue is not in the 128K ROM, nor
is it in System 3.2, the mainstay Mac Plus system version.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Kent Borg)
Date: 16 Mar 92 06:23:05 GMT
Organization: Camex Inc., Boston MA

OK, tell us about the Seattle font.  I have always wondered about it.


- --
Kent Borg                            internet: [e-mail]   AOL: kent borg
                                            H:[phone]  W:[phone]
"Eating healthy beef is not healthful, the steer will take offense at you
chewing on his flanks."      -me

+++++++++++++++++++++++++++

From: [e-mail] (Tom Dowdy)
Date: 30 Mar 92 16:24:20 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Kent Borg) writes:
> OK, tell us about the Seattle font.  I have always wondered about it.

The Seattle font (a tale of woe, in 3 acts)

Act 1:
  The Macintosh was released, and lots of folks started creating software
for it.  One company in particular made lots of software right away,
and they even went so far as to make their own font - for use in all
of this software.  They liked the font so well (and how it printed
on the ImageWriter) that they didn't give their users any way to
change the font in these applications.

Act 2:
  The LaserWriter was developed.  There were many many user documents
in the world that were not formated using the (heretofore unavailable)
LaserWriter fonts - Helvetica, Times, Courier, and Symbol.  And so
the LaserWriter team decided to include a "feature" called Font Substitution.
The purpose was to map the popular ImageWriter fonts (Geneva, New York,
Monaco) to their closest LaserWriter fonts - thus users could get
"high quality" documents without the need to change fonts.  It was
a cheesy move - but users who had spent $6000 on a new printer expected
existing documents to suddenly "come to life"

Act 3:
  Suddently, it was realized that there was all of this
software (and documents) which used a special font - with no way
for users to change the font.  And so it was decided to attempt to
mimic the Seattle font as a slightly larger Helvetica.  Thus 12 point
Seattle mapped to 14 point Helvetica.  And so it was that the
LaserWriter driver special cased for a third party font.

The End.

 Tom Dowdy                 Internet:  [e-mail]
 Apple Computer MS:81KS    UUCP:      {sun,voder,amdahl,decwrl}!apple!dowdy
 20525 Mariani Ave         AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

From: [e-mail] (Owen M. Hartnett)
Date: 1 Apr 92 01:19:27 GMT
Organization: Brown University Department of Computer Science

In article <[e-mail]> [e-mail] (Tom Dowdy) writes:
>In article <[e-mail]>, [e-mail] (Kent Borg) writes:
>> OK, tell us about the Seattle font.  I have always wondered about it.
>
>The Seattle font (a tale of woe, in 3 acts)
>
[3 acts of woe deleted]

>
>The End.

Hmmmm......

Now what major software corporation would be located near Seattle????


Thanks, Tom, we like sordid tales like this.

- -Owen

Owen Hartnett                [e-mail]
"FAITH, n. Belief without evidence in what is told by one who speaks
        without knowledge, of things without parallel."
            -Ambrose Bierce - The Devil's Dictionary

---------------------------

End of C.S.M.P. Digest
**********************